This invention relates to printers that are compatible with PostScript language programming, and to PostScript graphics language interpreters that are used within such printers.
The PostScript graphics language is a simple interpretive programming language with powerful graphics capabilities. Its primary application is to describe the appearance of text, graphical shapes, and sampled images on printed or displayed pages. A program in this language can communicate a description of a document from a composition system to a printing system or control the appearance of text and graphics on a display. The description is high level and device independent.
PostScript is a trademark of Adobe Systems Incorporated. However, the PostScript trademark is used in conjunction with a widely used and well-defined standard. Adobe Systems has authored a book entitled PostScript Language Reference Manual: Second Edition, published by Addison Wesley, 1990, which sets forth the current PostScript language standard. This book is hereby incorporated by reference. Although standards such as the Postscript language standard tend to evolve new features, Adobe Systems has endeavored to limit such evolution to well-publicized xe2x80x9clevels,xe2x80x9d and to ensure that new levels are upwardly compatible with previous levels.
The PostScript language includes powerful facilities for describing the colors of graphical objects to be marked on the current page. The color facilities are divided into two parts:
Color specification. A PostScript language program can specify abstract colors in a device independent way. Colors can be described in any of a variety of color systems or color spaces. Some color spaces are related to a device color representation (gray scale, RGB, and CMYK); others are related to human visual perception (CIE-based). Certain special features are also modeled as color spaces: patterns, separations, and indexed color mapping.
Color rendering. The PostScript interpreter reproduces colors on a raster output device by a multi-step process that includes color conversions, gamma correction, halftoning, and scan conversion. Certain aspects of this process are under PostScript language control. However, unlike the facilities for color specification, the color rendering facilities are device dependent and ordinarily should not be modified by a PostScript program.
Colors are specified as values having one or more color components. A color component is usually a number. For example, a gray value can be specified by a single number, ranging from 0.0 (black) to 1.0 (white). A full color can be specified in any of several ways. A common method uses three numbers to specify red, green, and blue components.
Color values are interpreted according to the current color space. There are three categories of color spaces:
Device color spaces collectively refer to several methods for directly specifying colors or gray levels that the output device is to produce. These methods include RGB (red-green-blue), HSB (hue-saturation-brightness), and CMYK (cyan-magenta-yellow-black).
CIE (the Commission Internationale de l""Eclairage) has created an international standard for color specification. Colors can be specified in the CIE-based color spaces in a way that is independent of the characteristics of any particular output device. One CIE color space uses parameters designated as X, Y, and Z.
Special color spaces add special semantics to an underlying color space. They include facilities for patterns, indexed color mapping, and separations. Since the invention does not involve special color spaces, they will not be included in the following discussions and will not be shown in the accompanying drawings.
Color spaces, including specific examples of the color spaces implemented in the current PostScript standard, are explained in more detail in the PostScript Language Reference Manual cited above. Generally, the device color spaces enable the specification of color values that are directly related to their representation on an output device. The color values map directlyxe2x80x94or via simple conversionsxe2x80x94to the application of device colorants such as quantities of ink or intensities of display phosphors. CIE-based color spaces, on the other hand, allow the specification of color values that are related to human visual perception. The goal of the CIE standard is for a given CIE-based color specification to produce consistent results on different output devices, up to the limitations of each device.
For clarify in the following discussion, device color spaces and color values specified in device color spaces are referred to as device-dependent color spaces and device-dependent color specifications. CIE-based color spaces and color values specified in CIE-based color spaces are referred to as device-independent color spaces and device-independent color specifications, respectively.
FIG. 1 shows major PostScript language features or operations, implemented by a software-based PostScript interpreter, for rendering color. The organization of FIG. 1 is defined by the PostScript standard, and is published in the PostScript Language Reference Manual (referenced above). Although the representation of FIG. 1 is somewhat simplified, it shows the standardized components that are relevant to the invention.
Colors can be specified in device-dependent or device-independent color spaces. A color specified in a device-dependent color space is referred to in FIG. 1 as a device-dependent color specification. A color specified in a device-independent color space is referred to in FIG. 1 as a device-independent color specification.
Device-dependent color specifications are processed first by a color conversion function 20. A PostScript language program can contain commands that request explicit conversions between device-dependent color spaces. Any such requested conversions are performed by color conversion function 20.
The interpreter then maps the device color values through transfer functions 21xe2x80x94one transfer function per color component. The transfer functions compensate for peculiarities of the output device, such as non-linear gray-level response. This step is sometimes called gamma correction.
If the output device cannot reproduce continuous tones, but only certain discrete colors, such as black and white pixels, the interpreter invokes a halftone function 22, which approximates the desired colors by means of patterns of pixels.
Finally, the interpreter performs scan conversion (not shown) to paint the appropriate pixels of the raster output device with the requested colors.
Device-independent color specifications are processed first by a CIE conversion function 23, also referred to as a color space array (CSA), and then by a color rendering dictionary (CRD) 24. The CIE conversion function 23 converts device-independent color specifications to a base device-independent color space that uses components referred to as X, Y, and Z. Color rendering dictionary 24, in turn, transforms the device-independent color specifications into device-dependent color specifications. Specifically, the color rendering dictionary converts the device-independent color specifications to a native device-dependent color spacexe2x80x94taking into account the known properties of the output device. The goal of this process is to produce actual visual output that accurately reproduces the requested device-independent color values as perceived by a human observer on the final rendering medium.
The color rendering dictionary is a standardized component of a PostScript language interpreter. However, its specific parameters are device dependent and are determined during a calibration process that is not specified by the PostScript standard. The color rendering dictionary can be configured to reference a three-dimensional lookup table to find device-dependent values corresponding to specified device-independent values.
The configuration shown in FIG. 1 is implemented in what is referred to as xe2x80x9cLevel 2xe2x80x9d of the PostScript language standard. The previous version of the standard, referred to as xe2x80x9cLevel 1,xe2x80x9d did not include the concept of device independent color spaces. Accordingly, it did not include components 23 and 24 of FIG. 1, which relate to converting device-independent color specifications to device-dependent color specifications. Because of the differences between Level 1 and Level 2 of the PostScript language standard, the color processing path for device-dependent color specifications is referred to as the xe2x80x9cLevel 1 color pipeline.xe2x80x9d The color processing path for device-independent color specifications is referred to as the xe2x80x9cLevel 2 color pipeline.xe2x80x9d
The PostScript architecture described above provides a great degree of flexibility through its various color conversion components: color space array 23, color rendering dictionary 24, color conversion function 20, transfer functions 21, and halftone function 22. However, this flexibility comes at the price of speed. As specified in the PostScript standard, the components are implemented in softwarexe2x80x94by a language interpreter. This tends to be very slow. As an example, the standardized color rendering dictionary must be implemented in a very inefficient way due to the constraints imposed by the PostScript standard.
More specifically, the PostScript standard allows PostScript programs to dynamically specify and configure these color conversion components. For example, the CRD can be dynamically configured by use of the xe2x80x9csetcolorrenderingxe2x80x9d operator. To provide such configurability, the color rendering dictionary uses bulky and inefficient data structures, containing large amounts of ASCII data. It is difficult or impossible to enhance the efficiency of these data structures without sacrificing compatibility with the PostScript standard. These comments apply generally to the various color conversion components of the PostScript architecture.
Furthermore, the color conversion components typically implement extensive mathematical and/or algorithmic operations on input values in order to find corresponding output values. These operations include range checking, encoding, decoding, interpolations, and matrix transformations. Such operations become very slow when implemented in an interpreted language.
One way to increase the speed of these components would be to implement them in hardware rather than software. However, this has been difficult to accomplish because the algorithms and transformations performed by the conversion components can by dynamically specified, during color rendering, by graphics language commands. Although default algorithms and transformations are typically provided, print jobs can specify replacement algorithms and transformations at any time, making hardware-based conversion components useless. Thus, it has been previously thought that hardware-based solutions would not provide compatibility with the PostScript standard.
Indeed, absolute compatibility with the PostScript standard is a very important requirement. One reason for the popularity of the PostScript language is that any PostScript program can be executed by any PostScript-compatible rendering device, and will result in nearly identical results. Printer manufacturers, as a result, have been very hesitant to alter the structure of the color rendering paths in any way.
Nevertheless, the prior art methods of implementing dynamically-changeable color conversion components are significantly slower than they should be. The inventors have found a way to remedy this shortcoming of the prior art.
In accordance with one aspect of the invention, one or more color conversion components are associated with a lookup table. The lookup table is initialized with data calculated by the color conversion components. During actual rendering, color conversions are accomplished with the lookup table rather than the color conversion components. When new transforms are specified by graphics commands, the lookup table is reinitialized by the newly configured color conversion components before performing further rendering. A cache is preferably implemented to store lookup tables corresponding to different color transforms and transformation algorithms.
In accordance to another aspect of the invention, each lookup table contains only a limited number of transformations, and additional transformations are obtained by interpolation. Such interpolation is preferably performed by hardware designed specifically for this purpose, rather than by instruction-based logic.
Various configurations of lookup components to PostScript color conversion components are possible. In the described embodiment, both the color space array and the color rendering dictionary are associated with a single lookup table, while another lookup table is used to perform the conversion and transformation functions of the PostScript level 1 pipeline. Conversion components of ICC profile-based systems can also be associated with such lookup tables.